This PR now also closes #87.

Following the suggestion of @ronvree ComputeConfig is now initialized to the current default pytorch values, such that it is easier for the user to avoid type/device conflicts.

This PR now also closes #87.

Following the suggestion of @ronvree ComputeConfig is now initialized to the current default pytorch values, such that it is easier for the user to avoid type/device conflicts.

Perfect thanks a lot! Sorry to be so difficult about this but I had one more concern in our previous discussion that I feel has not been addressed, namely that ComputeConfig stores a dtype/device as global/class properties which, if I understand correctly, prevents a user from having two instances on different devices. What are your thoughts about making device/dtype tied to model instances? Thanks again for picking this up!

Hi @ronvree, thanks for the suggestion!

Yes it makes sense to allow different instances to have different device/dtype.
I have implemented this feature by storing the ComputeConfig setting in each instance during initialization, so now you can do something like

# Create model on GPU 0
ComputeConfig.set_device("cuda:0")
model1 = Model() # captures cuda:0

# Create model on GPU 1
ComputeConfig.set_device("cuda:1")
model2 = Model() # captures cuda:1

while retaining all the advantages of having a global container to synchronize the different models and submodels.

I have also added test_config.py::TestComputeConfig::test_models_capture_config_at_initialization to test this feature and confirm that it works as expected.

@SCiarella Perfect thanks a lot!!

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud